Currently the list is:
The following developers have committed to supporting IC in some future release of their products:
Quinn 17 September 1995
We have no control over any other application vendors. If you would like your favourite application to support IC then I suggest you lobby your application vendor directly. Please don't mail us.
A lot of application developers implement features in order of the number of people who request them. If more people ask for IC support, it will probably receive more attention.
Quinn 17 September 1995
Internet Config was written by Australians and is localised for Australia. [If you don't believe us then check out the 'vers' 1 resource.] Thus it uses the Australian spelling for "organisation".
Chris Newman has graciously volunteered to localise IC for the US.
And while on the subject of localisation, Jean-Pierre Kuypers has localised IC to French.
Finally Michael Grinner has localised IC to German.
Thanks to all our localisers.
Quinn 17 September 1995
The Internet Config system is suitable for use in situations where Macs are shared by multiple users. It offers two mechanisms to support this. The first is centred around the mechanism used to locate a preference file. When an application is launched using a preference file then it should provide the folder that contains that preference file to Internet Config (using the ICFindConfigFile call) so that IC can look for a shared preference file in that folder. IC will follow aliases to the preference file so that this solution scales for multiple applications. The initial IC Aware release of NewsWatcher demonstrated this ability to good effect.
In addition applications call the Internet Config extension through a patchable Application Program Interface (API). So an enterprising third party can write a replacement for the current Internet Config extension that gets preference data from a shared database. The Internet Config RandomSignature extension is a demonstration of the technology used to do this.
See FAQ 6 for an example of how to set up IC on a shared Mac.
Quinn 4 Dec 1994
Internet Config's support for Macs in shared or laboratory environments is discussed in FAQ 5. This purpose of this text is to give specific advice. The setup described here is somewhat complicated and you may wish to investigate alternative tools, such as Mr Prefman.
At the moment when you use a shared Mac you use NewsWatcher by having two separate preference files and each user launches the appropriate preference file to read news. NewsWatcher reads its preferences from the file you launched, not from the file in the preferences folder.
Internet Config builds on top of this scheme. You simply place an alias to your Internet Preferences file in the same folder as your NewsWatcher preferences file. When other applications support IC they should use the same technique.
So let's take a look at a hypothetical Macintosh with two users, Fred and Sheila, running Eudora (assuming Eudora ever actually supported Internet Config) and NewsWatcher. In Fred's folder there is a Eudora Folder which contains a Eudora Settings file and a News folder which contains their NewsWatcher Preferences file. Fred launches these when they want to read mail and news respectively. Sheila's folder contains a similar setup.
Fred and Sheila get together and install Internet Config. They do this by creating two different Internet Preferences files (the Interent Config application lets you open, edit and close preference files just like normal documents) and putting them in their respective user folders. Sheila then puts an alias to her Internet Preferences file into her Eudora Folder and another alias into her News folder. Fred does likewise.
Now when Sheila launches NewsWatcher, by double clicking her NewsWatcher Preferences file, NewsWatcher will tell IC to get shared preferences from the Internet Preferences file whose alias is in Sheila's News folder. And Eudora would work similarly (if it supported IC).
Quinn 17 September 1995
Let me explain some of the rationale behind the design of IC. The most important thing, about IC is that although it took a lot of time and energy to write, it's not a success until even more people put in even more time and energy into adopting it. So one of the primary marketting targets for IC was application developers. We just assumed that the users would like it.
So what do application developers like? In a word, simplicity. Things that are easy to understand are more likely to get adopted. So we tried to keep IC as simple as possible while still not losing any critical funcionality.
There were two major features that were candidates for inclusion but which eventually got left out. The first was the concept of application specific preferences. Some users will obviously want a different signature in news and mail. We left this feature out because it would have complicated the implementation of the IC application too much. But we did leave ourselves an escape hatch. All applications identify themselves to IC by their creator type (eg 'Arch' for Anarchie) and thus it is possible to write an alternate IC extension that does this.
The second major feature which we left out was the ability to mark preferences are either 'user' and 'system' preferences. We left this out for much the same reasons as given above. And again, we left ourselves an escape hatch. Preferences can be marked read-only, in which case applications should not allow the user to edit them or attempt to write them back. So a lab oriented IC extension could mark system preferences as read-only (which would prevent the vast bulk of applications modifying them) and user preferences as read-write. It would then have to provide an alternative mechanism to allow modification of system preferences.
There was some debate on the mailing list about extending the IC API to provide a flag on the ICSetPref call that marks whether the setting should be stored 'locally' or 'globally'. The primary problem with this was that by choosing a meaning for 'local' and 'global' we would have restricted ourselves to one of the two major features discussed above. We decided that the best solution was to leave this problem for the future but do our best to make it easy to implement.
So, in conclusion, let me reiterate that the primary goal of this version of IC was simplicity for the programmer. Judging by the responses we've got from the first developers to adopt the system, we have been successful. And in the final analysis if lab managers are to gain any benefit from IC, it must first be adopted by a wide variety of developers.
As an aside, at the Apple World-Wide Developer's Conference in San José in May 1995, Apple gave details on a forthcoming Macintosh operating system, code named Copland, which has good support for multiple users on a single machine. This operating system will fix these problems in a supported manner.
Quinn 13 May 1995
The Internet Config Programmer's Kit is available from Australia or the USA.
This holds all the information you need to develop for Internet Config in Pascal or C using any of the common development environments (Metrowerks, Think and MPW). The kit also contains the source code to the Internet Config Extension.
The same sites also contain the Internet Config Application Source Kit, which contains the source code to the Internet Config application (in Metrowerks Pascal).
Lawrence D'Oliveiro has converted the IC interface files for use with Modula-2.
Mel Patrick has done some work with IC in FutureBasic.
Rick Giles is willing to answer questions related to IC and Prograph (and he's got it working, so what's your excuse?).
See FAQ 19 for details on programming IC in AppleScript and HyperCard.
Quinn 17 September 1995
Internet Config installs an extension which acts as a shared library. This extension provides an Application Program Interface (API) to the Internet preferences database. It is vitally important that applications access this database through the API and this text will explain why.
Firstly the API provides reliability and robustness. If IC was implemented merely through a shared preference file then each application developer would have to write their own code to access this data. Not only is this more work for the individual developers, it also increases the likelihood of an error that causes preference corruption.
To get around this we could have shipped IC as a statically linked library that each developer links into their application. The disadvantage of this is that if that library has bugs then it's statically linked into lots of old versions of applications that are never updated. [A classic example of this sort of problem is the original MacTCP DNR library, which looks for DNR data in the System Folder. Unfortunately with the advent of System 7 the DNR data moved into the Controls Panel folder. To get MacTCP working with System 7 Apple were forced to create a MacTCP DNR file in the System Folder anyway, just to support those old applications.]
So the IC API had to be in the form of a shared library. Unfortunately the Mac does not provide any suitable mechanism for providing shared library so we chose to implement it using a component. [The Component Manager originated with QuickTime and was rolled into the system with System 7.1. Virtually all Macs have the Component Manager or can get it easily.] So the API's statically linked glue calls the component if it's install but otherwise accesses the IC Preferences file directly. This provides the best of both worlds: the code works on old machines and without the extension but it can be patched by simply dropping a new version into the Extensions folder.
Finally the IC API gives a huge amount of flexibility for future extension. Imagine you want your preferences to be stored on a per-application basis, or you want your preferences fetched from a central network database on a per-user basis, or you want your signature to change every Friday the 13th. Well you can patch the existing Internet Config extension (or write a complete drop-in replacement) that provides this functionality and, as long as it provides a backwardly compatible API, none of the IC Aware applications have to be changed.
An example of the cool technology that API provides is the Internet Config RandomSignature extension provided in the Programmer's Kit. While this is only a technology demonstration it shows how the API can be patched to provide all sorts of cool things that the original designers did not anticipate.
The IC component patches no traps and does no strange things. It should not suffer from extension conflicts. It doesn't even show up in the System 7.5 Extension Manager list!
Quinn 7 Dec 1994
Internet Config resolves aliases to preference file. Put the real Internet Preferences file in one of your Preferences folders and an alias to it in the other.
Quinn 6 Dec 1994
The short answer to this is "Because double clickable preferences documents are a kludge and this restriction is an artifact of their kludginess."
The long answer is that IC targets applications (when doing things like sending GURL events to process URLs) based on their creator code. This is a three step process. First we find it in the desktop database, then we launch it, then we send it a GURL event. The two steps are skipped if the application is already running.
If we'd allowed you to specify a preferences file then we would have had to send the application two events, first the open document event (to open the preferences), then the GURL event. This is OK when the application is not running but what if it is running? Do we send the open document event, which may or may not cause the application to switch to that user's settings [Eudora does but NewsWatcher doesn't], and then the GURL event, or do we just send the GURL event and hope. The answer to this problem was to avoid the issue altogether by only allowing you to target applications.
The workaround is to launch the application using its preference file before you use it via command clicking or to eliminate double-clickable preferences entirely using a tool such as Mr Prefman.
Quinn 17 September 1995
Lots of people complain about not being able to enter type and creator directly into the Add Map Entry dialog. Well you always could do this by holding the option key down in the dialog, but since this seemed to be too well hidden for all those (non?) Power Users out there, we've made the fields directly editable in IC 1.2.
Quinn 17 September 1995
Internet Config, and its source code, is in the public domain. This has the following consequences:
Quinn 21 June 1995
The Internet Configuration System was designed to make your life easier by reducing the number of times which you need to enter your Internet preferences into the various preferences dialogs of all your Internet applications.
For example, currently you need to enter your Email address into many common Macintosh Internet applications, for example Eudora, NewsWatcher and Anarchie. The goal of the system was to get each of these applications to get this information from one common place and to give you a tool to edit these common preferences.
It is important to realise that applications will have to be modified to take advantage of the Internet Configuration System. It will take some time for all applications to be revised and until then you will have to enter your preferences in those applications in the traditional manner. You can find a list of the applications that currently support Internet Config in FAQ 1.
Quinn 27 June 1995
Never. Of course this does not preclude some enterprising Windows programmer from using the idea. Let's face it, they get most of their good ideas from the Mac ( :
Quinn 27 June 1995
Each new release of Internet Config is posted to MacGifts and is therefore available Info-Mac and UMich (and their mirror sites). It is also available from any site that holds Peter Lewis' software, namely AOL, AMUG, PopCo, Australia, Japan, and Switzerland.
Internet Config is also available as a NewsWatcher helper and on the TidBITS site.
Also see FAQ 4 for the location of various international versions of IC.
Finally, all sorts of IC related material, including the latest version of the IC software, is available from the IC home sites in Australia and the USA.
A big thank you to all our distribution sites.
Quinn 17 September 1995
The latest version of IC is version 1.2.
Quinn 17 September 1995
The formula for IC 1.1's memory usage is something like this...
total_bytes_used = k1 + n * (152 + 144 + k2) + f(n)
... where ...
n is the number of connections open to IC
k1 is the Component Manager overhead for registered components
k2 is the Component Manager overhead for component instances
f(0) = 0
f(x) = 16940, where x > 0
This assumes you're not running any other IC extensions, specifically ICeTEe or RandomSignature.
For a system running Anarchie and NewsWatcher, IC is consuming about 18K. The vast bulk of this is the IC code size (as determined by the function f) which is resident in the system heap and shared between all instances.
Wasn't that fun?
IC 1.2 takes a bit more. :-)
Quinn 17 September 1995
There are currently two ways of accessing IC from AppleScript. The first program is Internet Config Access written by Lawrence D'Oliveiro, and the second is ICScriptor by Leonard Rosenthal.
To access IC from HyperCard there are also a number of choices. Your best bet would be to use HyperCard 2.2 and then use one of the AppleScript options.
Alternatively you could pester me a lot and I may get around to fixing and then releasing the IC XCMD that I used to prototype the Internet Config application. Somewhere along the line it broke and I've yet to fix it. If you need to access IC from HyperCard, and have a good reason why you can't use HyperCard 2.2, drop me a line and I'll see what I can do. [Personally, I don't think pestering him will get you anywhere - Peter]
Quinn 17 September 1995
The decision as to whether to require IC is made by individual application developers. There are a number of factors that influence this decision. This entry attempts to give you some insight into the reasons why some programs require IC and others don't. Througout this discussion I'll use examples from programs that I'm familiar with, although the reasoning is pretty general.
The first factor is whether the program has an existing user interface for editing preferences. For example, Fetch already has a UI for file type mapping and thus it's easy to selectively enable this depending on whether IC is installed or not. On the other hand, Anarchie never had a UI for editing this preference, so it's easier to require IC than to have a bunch of preferences that can't be editted.
The second factor is criticality. Symantic Program Managers uses IC to support command-clicking. Obviously this functionality is non-critical and it's easy to disable just this feature if IC is not avaliable. The same is not true of CyberFinder, which really needs IC (or some other user interface, qv the first point) to provide this preference information.
The third factor is size and reliability. If your program needs information provided by IC then you have the choice of either requiring IC or providing a backup preference editing mechanism. This backup needs to be included in all your programs and contributes to making the them bigger, both on disk and in memory. Also, as bugs tend to be directly proportional to lines of code, this implies that your programs have more bugs. For example, ICeTEe requires IC because its code size would be hugely increased by providing a UI for editing preferences. And, because ICeTEe is an extension, providing this UI would have been a much greater compatibility liability. Requiring IC is a step towards smaller and more reliable code.
The fourth factor is time to market. If Anarchie was delayed while Peter wrote a UI for editing the file type mappings, it would have taken longer to get on the market. Or, for another example, the authors CyberFinder would never have been able to produce a fully functional program if they'd stopped to implement a helper editing dialog.
The biggest factor on the negative side is the potential user confusion caused by shipping a product that requires some other product. The other biggie -- the potential business liability involved in shipping a program that is dependent on a program not created by your company -- has been solved by us putting IC (and its source code) in the public domain.
Quinn 22 Aug 1995
Because every time I create a new entry I copy and paste this entry.
Quinn 6 Dec 1994
Comments: internet-config@share.com